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Signals are a lightweight form of interprocess communication in Unix. When a process receives a 
signal, the control flow is interrupted and a previously installed signal handler is run. Signal handling 
is reminiscent both of exception handling and concurrent interleaving of processes. In this paper, we 
investigate different approaches to formalizing signal handling in operational semantics, and compare 
them in a series of examples. We find the big-step style of operational semantics to be well suited 
to modelling signal handling. We integrate exception handling with our big-step semantics of signal 
handling, by adopting the exception convention as defined in the Definition of Standard ML. The 
semantics needs to capture the complex interactions between signal handling and exception handling. 

1 Introduction 

In operating systems, and specifically Unix and its descendants, signals provide a simple and efficient, 
if rather low-level, means of interprocess communication iTlOl rT4l n~6l fTST [3ll . Put simply, a process can 
cause a branch of control in another process, causing it to run a signal handler in response to external 
events. A well known example is the kill signal telling a process to shut down (perhaps after first 
deallocating system resources, such as releasing memory). 

Signals resemble exceptions in that control jumps to a handler that can be installed by the program. 
Nonetheless, there are some significant differences. Whereas exceptions typically abort from the con- 
text, in which they were thrown rather than returning to it, signal handlers resume control after they have 
run. Whereas exceptions are triggered at specific points by the code itself, signals arrive nondetermin- 
istically. In the literature on control constructs and their semantics, signals have received less attention 
than exceptions, and far less than first-class continuations. 

Exceptions have become amenable to semantic analysis by a focus on their key control features, while 
abstracting away from implementation details and restrictions (such as the entanglement of exceptions 
in C++ with the class hierarchy and memory management by destructors). For instance, the exceptions 
monad lfl2l gives a highly idealized account of exceptions as functions A — > (B + E) that may either 
return normally with a B or raise an exception of type E. 

The aim of the present paper is to address signal handling at a level of generality and abstraction 
comparable to that of other control constructs in the literature, idealizing where necessary and focusing 
on some key semantic features. Our motivation for defining such a semantics, and exploring different 
styles of definition, is to develop of a Hoare logic for signals. While program logic is beyond the scope 
of the paper, it is a reason for our investigating the big-step style of operational semantics. In big-step, 
a command c takes a pre-state s\ to a post-state S2 in a judgment of the form s\,c JJ- S2- This form of 
judgment is particularly convenient for proving the soundness of Hoare triples {P}c{Q}, since the pre- 
condition P refers to the pre-state s\ and the postcondition Q to the post-state S2 in a big-step judgement. 
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Outline of the paper 

We begin by reviewing the constructs that we will need, and how to define operational semantics for 
them, in Section 12 We then combine these constructs and define the semantics for the whole language in 
Section [3] To validate our definition, we examine how signal and exception handling interact in a series 
of examples in Section [4] As an alternative to big-step semantics, we define a small-step semantics as 
a stack machine in Section \5\ and relate it to implementations. We compare the stack machine to the 
big-step semantics in Section [6] Section |7]concludes. 

2 Language constructs 

Before giving the formal definition of our operational semantics, we introduce the language constructs 
with their intended meaning, as well as design choices and simplifying assumptions. We start from a 
small imperative base language. This language has a standard semantics in terms of how a command c 
changes the state si into a new state s 2 . In a big-step operational semantics, the form of such judgements 
is 

s\,ctys<z 

When the command c raises an exception e after producing the new state s 2 , we write 

si,cile,s 2 

Exceptions 

The semantics of exceptions is fairly well understood, and it is greatly simplified by the fact that 
exceptions are block structured. The more primitive non-local jumps in C (given via the library functions 
s et j mp ( ) and 1 ong j mp ( ) ) would be much harder to formalize. Exception throwing and handling is easy 
to add to a big-step operational semantics. A classic example of such a semantics is the Definition of 
Standard ML [11], whose style we will follow. 

In addition to the rules for the operations themselves, we also need to specify how the propagation 
of exceptions interacts with the other constructs of the language: this propagation will be done with the 
exception convention from the Definition of Standard ML. If the j-th premise of a big-step rule raises an 
exception, and the premises to its left do not, then the conclusion of the rule raises the same exception, 
and with the same state. 

More precisely, suppose there is a big-step rule of the form 

...C\$S\...Cj$Sj...C n $ s n 

...cJJ-j 

Then we implicitly extend this case to propagating exception by adding a rule 

...c\ $s\...Cj$e,Sj 
...cte,sj 

To illustrate the exception convention, we consider how exceptions are propagated in a sequential com- 
position C\\C 2 . 

s\,c\$e,S2 Ji,ci 4J- J2 s 2 ,c 2 ite,s 3 

si,(ci;c 2 )te,s 2 si , (ci ; c%) ft e, s 3 
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Intuitively, the first command c\ may raise an exception, in which case the second command C2 has not 
run at all. Alternatively, c\ may terminate normally, and C2 may raise an exception. In either case, the 
combined command raises the same exception. 
Signals 

The main construct we aim to address is signal handling. Signal handling is a form of inteiprocess 
communication, so that for full generality we would have to address the concurrent interaction between 
a signal sending and a signal handling process. To keep the semantics as simple as possible, we address 
only the handling part of the signal mechanism, while the truly concurrent interaction between sender 
and receiver is left for future work. Rather than modelling the signal sender explicitly, only the point 
of view of the process receiving the signals will be assumed, so that signals arrive nondeterministically, 
causing handlers to run unpredictably. In the authors' view, this focus on signal handling still presents 
sufficient programming and semantics challenges. First, the nondeterministic interference by signal 
handlers leads to the need to preserve resource invariants, much as interference between concurrent 
processes. Moreover, the assumptions a programmer can make about the delivery of signals are very 
weak, even if there is a specification of the sender's behaviour (which there usually is not). In the worst 
case, the signal sender may even be malicious, sending signals with the sole intent of causing damage 
via the actions of the signal handlers. In that sense, a nondeterministic sender is a worst-case but realistic 
assumption that the signal receiver has to be able to cope with. 

As a language construct, signal handlers resemble both concurrency and exception handling. Our 
most significant idealization of signal handlers is directly inspired by exceptions in contrast to the un- 
structured longjmp that exceptions were designed to replace. We define an idealized block-structured 
form of signal handling in which a signal handler is installed at the beginning of the block and uninstalled 
at the end. It relates to sigaction the way exceptions related to setjmp and atomic synchronized 
blocks related to locking and unlocking. 

For the operational semantics, we define a big-step semantics. This style of semantics appears partic- 
ularly apt for the signals and exceptions kind of constructs. Essentially, the meaning of a block becomes 
a subtree of a larger derivation tree, which is convenient for keeping track of pre- and post-states. In the 
same way, the derivation tree of one-sided signal handler could be easily injected into a larger tree. 

One may think of addressing one-sided interleaving with the same approach as complete interleaving. 
This is true to some extent, but there are important differences between them. The interaction between 
fully concurrent processes is symmetric, but there is no such symmetry between the signal body and the 
handler. Only the signal handler may interrupt the body, but not vice versa. This allows using a simpler 
approach for addressing signal handling. On the other hand, the general approach used for the fully 
concurrent interleaving might not be suitable, as the interaction is non-symmetric. 

Figure [Qdepicts the symmetric interleaving of concurrent processes compared to the one-sided inter- 
leaving of a process by its signal handlers. Dashed horizontal lines represent control flow; dotted vertical 
lines represent switches in the control flow due to interleaving. In both cases, the state a, that a process 
sees at some point could has been changed to some state a i+ i by interleaved actions. These state changes 
need to be limited in some way, as otherwise no assumptions could be made by the process about the 
state, including resource invariants. 
One-shot and persistent signals 

Signal handlers can have two different control flow semantics, which we call persistent and one-shot. 
A persistent signal handler can be run any number of times as long as it is installed. By contrast, a one- 
shot signal handler can be run at most once, as it becomes automatically uninstalled after being run the 
first time. In Unix, the system call for installing handlers takes a parameter that determines which of 
these behaviours is chosen. 
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Figure 1 : Processes vs signal handlers 



Operational semantics 

In the operational semantics, the evaluation of a command c starting from a state s\ will now take 
place relative to a signal binding. Moreover, the signal binding is subdivided into two parts: persistent 
signals S, and one-shot signals O. Persistent handlers may run any number of times during the evaluation 
of the command c, whereas one-shot handlers may run at most once. The form of a big-step judgement 
with signal bindings is: 

S;0\~ si,c ij,s 2 

Note that the signal binding behaves like an environment (for variables bound via let) rather than a 
mutable state (for variables updated via : =). The judgement produces an updated state s 2 , but it does not 
update S or O. 

Analogous to binding an exception handler, we have two binding constructs for signals: one for 
persistent and one for one-shot handlers, where z is a signal name, q, is a command, and c/, is a handler 
command. 

bindztoc/, inc/, and bind/lztoc/, inc^ 
To support signal disabling in a scope, we introduce two blocking constructs for signals: 

blockzinc/, and block/lzinq, 

Note that there is no need for an analogue of throwe (a command that throws an exception e), as we 
assume that signals arrive nondeterministically from other, unspecified processes. The idea of using two 
contexts with a binder for each is loosely inspired by Barber and Plotkin's Dual Intuitionistic Linear 
Logic (DILL) HI. 



3 Operational semantics for block-structured signals and exceptions 

Definition 3.1 The syntax of the language with signal and exception handling is given in Figure [2] 

We let s range over states, c over commands, x over variables, v over values, e over exception names, 
z over signal names, and E over expressions, using subscripts where needed, e.g., e 2 , £3, C4 or c/,. s is 
a function from variables to values, such that s(x) returns a value v. 
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while (E) doc 
x := E 
c\;c 2 
throwe 



(while construct) 
(Assignment) 
(Sequential composition) 
(Exception throwing) 



try ci handle e by c 2 (Exception handling) 

bindztoci inc2 (Binding persistent signal handler) 

bind/lztoci inc2 (Binding one-shot signal handler) 

blockzinc (Blocking persistent signal) 

block/lzinc (Blocking one-shot signal) 

::= x \ E + E \ ... (Expressions) 

Figure 2: The syntax of the language 

S [z c\ ] ; O h si , c 2 JJ s 2 S; O [z ^ c\ ] h s\ , c 2 JJ 5 2 



S;Oh 5i,bindztoci inc 2 JJ 5 2 S;Oh 5i , bind/1 ztoci inc2 JJ- s 2 
S-z;0\-s u ctys 2 S;0-z\-s u ctys 2 



S; O h si , blockz inc JJ 52 



S;Oh *i, block/lzinc JJ 52 



S;0 h s, throw e f|- e, s 



S;0\\- s\,cii[e,s 2 S;0 2 \- s 2 ,c 2 i), s 3 
S; 0\ * 2 h S\ , try ci handle e by C2 JJ 53 

S;#i h Ji,ci ft e,52 S;C?2 l~ 5 2) c 2 ft £2)^3 



5;6> h 5i, ci Jj5 2 



5; h *i , try ci handle e by C2 JJ 52 
5;0 h 5i,ci f|" ^2^2 e ii^ e 



S,Oi *0 2 \~ 5i, try c\ handle e by c 2 f|~ £2,^3 S;Oh 5i,try ci handle e by C2 ft e 2 ,s 2 



shElv 



S;Oh s,x:=E ^s[x^v] 



S;Oi l-5i,ci Jj-52 5;0 2 I" ^2,^2 JJ53 
S'jOi *0 2 I - Ji,(ci;c2) JJ53 



5;Oh5i,ci Jj5 2 S(z)=c 2 0;0h5 2 ,c 2 JJ53 S;0-z\-s u ci^s 2 O(z) = c 2 0;0 h 5 2 ,c 2 JJ 53 
S;0 h 51, ci JJ53 5;6> h 5i,ci JJ53 

S(z)=c 2 0;0h5i,c 2 Jj5 2 5;6>h5 2 ,ci JJ53 0( z ) = c 2 0;0 h 5i,c 2 JJ 5 2 S;0-z h 5 2 ,ci JJ 53 
5;6> h 51, ci JJ53 5;6> h 5i,ci JJ53 

Figure 3: Big-step semantics rules for exceptions and signal handling 
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0\ [z^c h ](z) =c h 



0; h Ji , en JJ- S2 S;0\-z\- s 2 ,ci i}.s 3 



S;Oi [z^c h ] \~si,c\ tys 3 



S;0 2 r-s 3 ,c 2 i}- s A 



S;(O l *0 2 )[z^c h ] hs u (c 1 ;c 2 ) ^s 4 



S;Oi *0 2 \~ si,bind/lztoc/,in(ci ;c 2 ) \!ys 4 



Figure 4: Splitting of the O binding in seq. composed commands 



Some auxiliary definitions will be required for the operational semantics. For a partial function /, we 
write / [x \- > v] for the function that maps x to v and coincides with / on all other arguments. In particular, 
we use this notation for updating states or signal bindings. We write dom(/) for the domain of definition 
of a partial function. For x € dom(/), we write / — x for the restriction of / to (dom(/) \ {x}). A signal 
binding is a finite partial function from signal names z to commands c. We will need a partial operation 
on signal bindings. In fact, this definition is the same as the separating conjunction from separation 



Definition 3.2 Given two signal bindings 0\ and 2 , we define a partial operation * as follows: 

• If dom(Oi ) n dom(0 2 ) = 0, we write 0\ * 2 for 6>i U 2 . 

• If dom(Oi) ndom(0 2 ) / 0, then 0\ * 2 is undefined. 

It is this splitting of a signal binding, analogous to the heap-splitting of separation logic, that gives one- 
shot behaviour to signals. Specifically, in a sequential composition {c\,c 2 ), the one-shot signals are split 
non-deterministically between the commands c\ and c 2 . Moreover, every time a one-shot signal arrives 
and is handled, it is removed from the one-shot binding O. Thus, a one-shot signal may never be handled 
twice. 

Definition 3.3 Given two signal bindings S and O, the form of a big-step judgement is either 



for exception throwing. The rules are given in Figure [3] The exception convention is assumed implicitly. 

4 Examples 

We examine how signal and exception handling interact in a series of examples, and discuss the question 
of priority between them. 
Examples for signals 

The aim of the Figure 0] and Figure [5] is to show how one-shot and persistent signal bindings are 
"shared" between sequentially composed commands, and highlight the core difference between them 
(splitting versus copying). 

In Figure |U the one-shot signal binding O = 0\ * 2 (Definition 13.21 ) is split non-deterministically 
between commands c\ and c 2 . When the new signal z is registered, it becomes an element of the domain 
(0\ * 2 ) [z H> Ch\. However, is z € dom(C?i [z H> c/,]) or z G dom(C?2 [z Cf,]) will be determined 



logic [13]. 



S;0\~ si,c ij,s 2 



for normal termination, or 



S;0 h s\,c^e,S2 
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S[z^c h ]iz)=c h 0;0 h si,c h s 2 S[z^fc h ];0\- s 2 ,c\ ^ j 3 

5[zi-^c/,];0 h ji,ci JJ- j 3 ^ 
5[zi->-c^];0 h ji,(ci ;c 2 ) 4> ^6 
S;Oh s^bindztoc/, in(ci ;c 2 ) JJ- ^6 

S[z^c h ](z)=c h 0;0h j 3 ,c a JJ-j 4 ^ 
5[zi-)-c^];OI-J3,C2 

& = 

S[z^fCh\{z)=c h d);(Z)\- s 4 ,c h ij.s 5 S[z ^ c h ];0 \- s 5 ,c 2 ii- s 6 
S[z t-> h 54, C2 J|s6 

Figure 5: Multiple persistent signal handling in seq. composed commands 

0[z^Ci](z)=c/, 0;0h Ji,c fc JJ.j 2 5;0-zh5 2 ,c^5 3 
S;0 [z (->• c/,] h sy,c s$ 
S,0 h 5i,bind/lztoc/, inc JJ- 53 

Figure 6: One-shot signal handling before the command 

during the run time only. In this particular example, the signal z arrives in "scope" of the command c\ 
(z € dom(f?! [z 1 — y Cfo ])) and the bound handler runs. According to the one-shot signal binding nature, 
the binding for z is removed from 0\ [z i-> c/,] and consequently from (C?i * O2) [z >-> Qi] as C?i [z i-> 

^ (#i * 2 ) [z 1— ► c/,]. Therefore, z ^ dom(0 2 ) an d if the signal z arrives during the execution of the 
command c 2 , it will be ignored. 

In Figure [51 we focus on a persistent signal binding. The key difference with the one-shot binding is 
that the binding is just copied to the every command without splitting or modification. Thus, the same 
signal handler may run any number of times during the execution of the commands c\ and c 2 . This 
behaviour is possible because triggering a persistent signal handler does not remove the corresponding 
binding. 

Examples for signals and exceptions 

Suppose that a signal handler relies on some resource (valid pointer, open socket, active connection, 
etc.) available in the particular scope. However, as a side effect of the handler execution, the resource be- 
comes unavailable (freed pointer, closed socket, inactive connection). In this situation, multiple handler 
executions may lead to the program fail and abrupt termination. 

Obviously, one-shot signal handlers are perfectly fit for purpose. In Figure |6l the one-shot signal 
handler c/, runs before the command c. Thus, when control flow returns to c, the one-shot signal binding 
no longer contains a binding for the handler c/,. In Figure [71 the one-shot signal handler c/, runs after the 
command c, and at that point the signal binding no longer contains a binding for c/,. Note that the signal 
handlers (persistent and one-shot) that are still bound might be triggered if the corresponding signal 
arrives after the Ch- 

On the other hand, a persistent handler combined with an exception imitates one-shot signal handlers 
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S;0-z\~ Ji,cJJ- s 2 0[z^c h ](z) =c h 0;0 h s 2 ,c h JJ. s 3 
S; (9 [z !->-(;/,] h Ji,cJJ. j 3 
S;Oh S\, bind/1 z to c/, inc JJ- 53 

Figure 7: One-shot signal handling after the command 



0; h Ji , h JJ- j 2 0;0 H s 2 , throw e ^ e,s 2 
5 [z i->- (A; throwe) ](z) = (ft ; throwe) 0;0 h si, (ft; thrown) ff- e,s 2 

S[z h-> (ft ; throve) ];0 h si,c e, j 2 
5; I- (bindzto (ft ; throve) inc) ffe, j 2 S;0 h j 2 ,g J.I 53 

5; (9 h s\ , try (bindzto (ft ; throwe) inc) handle e by g JJ. 53 

Figure 8: Persistent handler with an exception triggered before the command 

to some extent. The key trick is in adding of a "throv " command to the end of the persistent handler. 
Because of a thrown exception, control leaves the signal block, so the persistent signal handler will not 
run again. 

In Figure [U the persistent signal handler runs and throws an exception. As exception propagation 
takes place, the command c does not run. In Figure |9l the command c runs before the persistent signal 
handler has been triggered. Thus, the raising of the exception does not influence the command c at that 
point. 

Comparing the derivation trees in Figure [7] and Figure |9j we observe how similar they are. In both 
cases, the main command runs first and then the signal handler runs only once. The only difference is 
that singular executions of the handler has been achieved by two different approaches. 

Comparing the derivation trees from Figure [6] and Figure [8) we observe the next situation: in both 
cases the strict condition (singular execution) for the signal handlers is satisfied, but as a "side effect" of 
an exception propagation (Figure [8]), the command c is skipped. 

5 [z 1— > (ft ; throwe) ],0 h S\ ,c JJ. s 2 S [z >->• (ft; throwe) ](z) = (ft; throwe) & 
S \_z ' — y (ft j throve) ];0 h Si , c ij e, S3 
S; O h *i, (bindzto (ft ; throwe) inc) ff e,s^ S; O h 53 , g JJ. 54 

S;0\~ si,try (bindzto (ft ; throwe) inc) handle e by g JJ. 54 

J* = 

0;0 h s 2 ,h JJ. s 3 0;0 I-53, throwe ffe, s 3 
0;0 h s 2 , (ft ; throwe) ff e,S3 

Figure 9: Persistent handler with an exception triggered after the command 
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S[z^h](z)=h 0;0h si,htys 2 S[z^>- h];0 \- s 2 , throw e i[ e,s 2 
S[z>-th];0\- s i, throwe ff e,S2 
5; h *i, (bindzto/j in thrown) ff e, s 2 S;0 h S2>g JJ- *3 

5;0 h *i,try (bindzto/2 in thrown) handle e by g JJ. 53 

Figure 10: Example of the derivation tree: a signal binding inside an exception block 



S[zt->h](z)=h 0;0h-Ji,A JU 2 S [z 1-4 /z];0hj 2 , throve ft e,j 2 

S[z h Ji, throve fte,^ ^ 

S[z 1— >• h]; O h 5i , try (thrown) handle e by g JJ. 54 
S; h 5i,bindzto/jin(try (throw e) handle e by g) JJ. 54 

S[z^h](z)=h 0;0h5 2 ,/jJ>5 3 5[zH-/z];Ohj 3 ,gJ|j 4 
5[z^/i];Ohj 2 ,gJ|J4 

Figure 1 1 : Derivation Uee for the combined signals and exceptions 

Interaction between signal and exception handling 

There is potentially a pitfall in combining signals and jumps (such as exceptions), in that a jump 
could prevent a handler from being correctly uninstalled at the end of its scope. In fact the problem is 
quite general, and arises whenever resource management is combined with jumping. In our language as 
defined in Definition 13. II such a potential problem case is presented by the following code: 

try (bindzto/zinthrowe) handle e by g 

The intended meaning is that the signal z is bound locally inside the body of an exception block. The 
signal handler may run immediately before the thrown command. However, once the exception has 
propagated to the exception handler, it has left the scope of the signal binding, so that the signal handler 
should not be able to run. To see that the big-step semantics (Figure [3]> correctly handles this case, 
consider the derivation tree in Figure [TOl 

In a big-step semantics, block structure is handled correctly "for free". The extended signal binding 
5 [z 1-4 h] is confined to the subtree of the body of the binding. When the body is left, the evaluation is 
resumed with the old 5, which is what is used in the evaluation of g. Even when control leaves the signal 
block abruptly via an exception, there is no danger that the signal handler escapes from its scope. By 
contrast, in a small-step semantics (e.g.: abstract machine) the uninstalling of signal handlers needs to 
be performed explicitly. 
The question of priority 

In our operational semantics, exception propagation has higher priority than exception handling. 
Thus, a signal might be handled only before the exception has been thrown and after it has been caught 
(Figure ITTb. The command throw does not change the state itself, thus the state remains unchanged until 
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S[z^h];0 h ji , throw e ft e,Ji S[z (->• fc](z) = 0;0 h si ,/2 J| s 2 
5 [z h-> /i]; h 5i, throw e ft e,S2 
S;Oh *i, (bindzto/zinthrowe) ft e,S2 5; h S2,g -IJ- 53 

S,0 h *i,try (bindzto/2 in thrown) handle e by g JJ. 53 

Figure 12: Signal handler runs after the throw 

the exception is caught, when there are different options: if no signal arrives then the exception handler 
runs, or else the signal handler runs first, and only then the exception handler proceeds. 

However, one can design an implementation where signal handling has higher priority. Thus, a signal 
handler should be processed even if exception propagation takes place (Figure [12]). In a semantics with 
signal priority, the state is changed by the signal handler even during the exception propagation. One 
can make a few interesting observation about it. During exception propagation, control flow exits nested 
blocks, which in turn may have different signal bindings. Thus, depending in which block a signal 
arrives, the corresponding handler will interrupt the exception propagation. In addition, it might be the 
case that the signal is blocked in that scope, thus propagation would not be interrupted. 

5 Stack machine for signal handlers 

We define an abstract machine in order to highlight some of the issues that may arise in possible im- 
plementations of block-structured signals, such as managing the stack. The implementation of signal 
handlers in our abstract machine was inspired by the real implementations of exceptions in contrast to 
the unstructured longjmp that exceptions were designed to replace. 

The defined block-structured form of signal handling requires a signal handler to be installed at 
the beginning of the block and uninstalled at the end. Therefore, to keep track of signal handlers in a 
particular scope, we use a signal stack. However, the addition of exceptions complicates the scoping 
of signal handlers. When control leaves a signal scope via a raised exception, the handler should be 
uninstalled. Thus, to implement the desired interaction between signal and exception scope, we keep 
track of signal handlers and exception handlers on the same stack. When an exception is raised, the stack 
is popped until the nearest enclosing handler for the exception name is found. The same popping of the 
common handler stack also removes any intervening signal handlers. 

A machine configuration is of the form (c \ s \ ft \ J \ K), where c is the expression that the machine 
is currently trying to evaluate, s is a state. The bit vector component j8 is used for keeping track of 
installed (not blocked) signals. J is a stack, which holds the signal and exception bindings. K is a 
continuation, which tells the machine what to do when it is finished with the current command c. The 
initial continuation is a special instruction return. The special symbol ■ is used to represent an empty 
stack in the components / and K. When we get ( return \s | /3 | ■ | ■ ) , program execution is finished. 
The full list of transition steps is given in Figure [13] To evaluate expression £ in a state s, we apply the 
function eval (Defintion l5.ll ). which returns a value v. 

j6° stands for a null bit vector (which means blocking or ignoring of all signals). The system instruc- 
tion pop-upd(/3') removes the top element from a stack J and updates j3 to /3'. The system instruction 
update (j3') updates j3 to /3'. We define J as a data structure that follows stack discipline except in the 
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(ci;c 2 | s\ | j3i |/i | K x ) 
{x:=E | J! | ft \Ji Ic'-Ky) 

(bindzto/zinc \s \ f3 \J\K) 
(bind/lzto/jinc | s | j3 | J \ K) 
(pop-upd(j3i) \s\Pz\(z,h),J\c;K) 
(c \s\p\J u (z,h),J 2 \K) 

(c \s\f5\J l ,(z,h,0),J 2 \K) 

(blockzinc | s | j3i | / | K) 
(block/lzinc | s | ft | / | K) 
(update (j8i) \s \ Pz\J\c;K) 
(try Cb handle e by h \s\f$\J\K) 
(throwei \ s \ p \ J\,(ei,h),J2 \ K\) 



■ {c\ | si | ft |/i | c 2 ;Ki) 

■ (c' |,n[jc.->.v] I 
where eval (E, si) =v 

■ (c | s | p+z | (z,h),J | pop-upd(j8);^) 

• (c |j|]3+z| (z,/i,0),7|pop-upd( j 8);^} 

• {c \s\pi\J\K) 

■ (h |j|j3° 1 7i, (z, ft), / 2 | update (j3);c; AT) 
handling of the persistent signal 

■ (h \s\P°\J x ,{z,h,l),J 2 | update (p-z);c;K) 
handling of the one — shot signal 

■ (c | s\fii-z\J\ update (ft);£) 

• (c | 5 | ft -z | / | update (ft); AT) 

• (c \s\fc\J\K) 

• (cb | s I j3 | (e,h),J | pop-upd(j3);X") 

where unwind (ei, (ei,/z),/2), ^1) = (h,fi' ,Ji,K 2 ). 



Figure 13: Transition steps 

case of one-shot signal handling. The J stack is manipulated by the system instructions that are pushed 
in and popped out from the continuation stack K. 

j6 is a function from signal names z, to Booleans. For each signal name z, j3(z) tells us whether the 
signal is currently enabled. Then j8 +z is a shorthand for /3 [z i — ^ true] and j3 — z stands for j8 [z H >• false]. 

For a thrown command, where ei € dom(7), we apply the unwind function (Definition l5.2l ). which 
returns a quadruple that is used to construct the next machine configuration. If e\ dom(7), then the 
machine gets stuck with an unhandled exception, in the sense that there is no transition for this configu- 
ration, so that 

(throwei | s | j8 | J \ K) -/> 

An exception binding tag has the form of (e,h), where e is an exception identifier, and h is a handler. 
A persistent signal binding tag has the form of (z,h), where z is a signal name, and h is a handler. A 
one-shot signal binding tag has the form of (z,h,u), where z is a signal name, h is a handler, and u is a 
bit indicating that the handler has been used once (u=l) or not (u=0). Handling of the one-shot signals 
requires update of the J stack; to be more precise, the bit u in (z,h,u) is updated. 
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Definition 5.1 (eval function) 



eval (x, s) 



eval (Ei +E2, s) 



evalCEi, s) 



+ 



eval (£2, s) 



Definition 5.2 (unwind function) 



unwind (ei, J, c;K) 



unwind (^i 



/, K) 



unwind(ei, 7, update(/3);^) 
unwindC^!, ((z,h),J), pop-upd(jS) ; K) 
unwind(^i, ((e\,h),J), pop-upd(jS) ; K) 



unwind (^i 



unwind (^i 



(h,p,J,K) 



J, K) 



J, K) 



Implementation of signals 

We compare how our idealized stack machine models features of real signal implementations. 
Bit vector In our machine, j3 stands for the bit vector of installed not currently blocked signals; and j8° 
stands for a null bit vector that may be interpreted as "all signals are blocked" or "no signals are installed". 
The use of this bit vector almost directly corresponds to the bit maps used in real implementations. In 
real implementations, every signal has a default pre-assigned handler. To imitate the same behaviour, 
in our implementation it is possible to run a command inside of nested blocks in which all signals are 
bound to their default handlers. 

Exceptions and signals In real implementations (as explained in (4), ISO/IEC 14882 HHH), exception 
throwing inside of signal handlers is not recommended, due to implementation restrictions. Moreover, 
the existing implementation of signals is not block structured. By contrast, our abstract machine and 
big-step semantics deal with block structured signals and allow signal handlers to throw exceptions. 
Implementation of exception handling In real implementations (e.g.: Itanium [5], and as described in 
iPTOl |4l 13), exception handling is implemented by use of stack unwinding. Exception handling in our 
implementation resembles handling in real implementations, except the fact that the abstract machine 
uses the extra stack J to keep track of block structures, and the J is manipulated by special instructions 
in the continuation K. 

6 Examples of the machine runs 

We have already seen in previous examples (e.g.: Figure [8] and Figure [TTb that the big-step semantics 
gives us block structure for free. This becomes very useful in studying block structured constructs and 
their interactions. By contrast, the machine needs to manage block structure explicitly with a help of the 
stack. The examples of corresponding machine runs are given in Figure [14] and Figure [15] Please note, 
the pop-upd(j3 ) 2 stands for pop-upd(j8°);pop-upd(j3°). 

The example in Figure 0] shows how the big-step syntax makes it easy to address one-shot signals 
with splitting the bindings. On the contrary, the machine needs to perform extra administrative work 
with the binding tags and the stack to implement one-shot signal handling (Figure [TBI . 

One may observe that the abstract machine is more complex than the big-step semantics, as machine 
needs to deal with many details explicitly. Overall, we see that the machine is closer to implementations, 
whereas the big-step semantics is more convenient for abstract reasoning. 
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(try (bindzto (h ; throwe) inc) handle eby g \ s\ \ (5 ■ return) 
~* (bindzto (h ;throwe) inc | s\ | /3 | (e,g) | pop-upd(/3 ) ) 
~» (c | j! |/3° + z|(z, (ft; throve)), | pop-updC/3 ) 2 ) 

~> ( (/i; throw e) | s 1 | j3° | (z, (ft; throw e)), | update (j8° + z) ;c;pop-upd(/3 ) 2 ) 

(/i | | j3° | (z, (/i ; throwe)), | throwe;update (j3° + z) ;c;pop-upd(j3 ) 2 ) 
-* (throw e |j 2 1/3° | {z,(h; throw e)),(e,g) | update (J8° + z) ; c; pop-upd (j3°) 2 } 
~* (g I s 2 | j3° I B | return) 
•w (return | 53 | j3° | ■ | ■) 

Figure 14: Binding inside of the try block 

(bindzto/iin(try (throwe) handlecbyg) | s\ | j3° | ■ | return) 
•w (try (throwe) handle e by g \ si | j8° +z | (z,/i) | pop-upd(/3 ) ) 
-w (throwe | Sl | j8° + z | (e,g), | pop-upd(j8 + z) ;pop-upd(j3°) ) 
-w (A | J! |/5° | (<?,g),(z,/j) | update (j3° + z) ; throwc; pop-upd ( j8° + z) ; pop-upd (J8°) ) 
-w (update (/3° + z) | 5 2 | /3° | (z,fc) | throwe; pop-upd (/3° + z); pop-upd (/3°) ) 
-w (throwc | s 2 | j3° + z | (e,g), (z,h) | pop-upd(/3° + z);pop-upd(/3°) ) 
~» (g |*2 |J8° + z| (z,A) | pop-upd (j3 )) 
•w (A | 52 |j3 |(z,/i)|update(i3 + z);^;pop-upd(i3 )) 

(update (j3° + z) | 5 3 I 0° | (z,A) | g; pop-upd (j3°) ) 

(g |*3 I J3° + z| (z,A) | pop-upd (jS )) 
-w (pop-upd(j3°) | 5 4 | /3°+z | (z,h) | return) 
-w (return | s 4 | j8° | ■ | ■) 

Figure 15: Exception handling inside of the binding 

(bind/lztoc/j in(ci ;c 2 ) | 5i | j3 | I | return) 
-w (ci;c 2 | Ji | j3 +z | (z,&i,0) | pop-upd(/3 );return) 
-w (ci | 5i | j8°+z | (z,^i,0) | c 2 ;pop-upd(/3°); return) 
~^ (/ji | *i | j8° | (z,&i, 1) | update(/3°);ci;c 2 ;pop-upd(/3°);return) 
•w (update(/3°) | j 2 | /5° | (z,Ai,l) | ci;c 2 ; pop-upd (/3°); return) 
-w (ci | 5 2 | j8° | (z,/ii,l) | c 2 ; pop-upd (j3°); return) 

(c 2 | 53 |j3° | (z,M,l) | pop-upd (/3°); return) 
~» (pop-upd(/3°) | 5 4 |/3° | (z, fci.l) | return) 
~* (return | j 4 | /3° | ■ | ■) 



Figure 16: Signal binding and seq. composed commands 



162 



Operational semantics for signal handling 



7 Conclusions 

The present paper idealizes signal handling in combination with the more familiar exception handling to 
focus on some of their semantic and logical features. The semantics of one-shot handlers is reminiscent 
of linearly-used continuations and the resource usage in separation logic lfl3l . The way we have 
treated signal bindings in the big-step semantics borrows ideas from linear logic. Recall that we write 

5; Oh S]_,cij,S2 

for a judgement involving a persistent signal binding S and a one-shot signal binding O. As we have 
illustrated with the examples in Section|4j the signal binding S can be shared between two commands c\ 
and C2 in a sequential composition, whereas O has to be split into disjoint parts 0\ and 02- This splitting 
prevents a one-shot signal handler from being re-used and makes it a linear resource just like the contexts 
in a linear logic. In fact, Dual Intuitionistic Linear Logic [1] has two zones T and A in the context, one 
which allows sharing and one which does not, as in the following rule that shares A and splits T: 

Ti;AhM:A^B r 2 ;AhN:A 
r 1 ,r 2 ;AhM^V:B 

We are not aware of previous operational semantics for signals, although Feng, Shao, Guo and Dong 
presents a program logic for assembly language with interrupts, which are analogous to signals at the 
hardware level. 

Hutton and Wright [7] study interruptions as asynchronous exceptions. By contrast, signals are a 
software alternative to hardware interrupts, where signal handlers could be addressed as asynchronous 
subroutine calls. 

Signals have been part of the long evolution of Unix, and are correspondingly complex. To implement 
block-structured signal handling and integrate it with exceptions, the present signal mechanism may have 
to be revisited. The present implementations pose severe restrictions on programmers, for instance on 
using non-local control in a handler. Removing such implementation restrictions would enable natural 
programming idioms. In further work, we hope to build on the operational semantics presented here for 
proving soundness of a Hoare logic for signals. 

The formal connection between the big-step operational semantics and the signals abstract machine 
remains to be established. We conjecture that they are observationally equivalent and that this may be 
proved by way of a simulation relation. 
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